End-to-end encryption and keys awareness

In order to use end-to-end encryption, it is enough to use a browser extension - it uses open pgp - open source for
encryption and keys and just inserts a button to gmail :)

https://youtu.be/aAXIqnjbc-M?t=106
Mymail-Crypt for Gmail at chrome store

quite radical, simple, but it can fall off :)

there is a more reliable way, but you have to manually encrypt it - another extension

(https://chrome.google.com/webstore/detail/pgp-anywhere/cdlcdnmhcodhagbmljapgbjdimjckilb) there is a more convenient
option - configure End to End Encryption in Thunderbird

(https://youtu.be/MvQYVhj4f9c) but, whatever one may say, there is always a good old problem - how to exchange public
keys at the very beginning, I recommend on twitter or github :)

but in general both the signal and the telegram will come down

and yet, why?

Open standards and open source software have a number of advantages

1. Transparency. Open source software is transparent. The source code is public and anyone can check it out

2. Confidence. Open source and open standards can be considered more reliable because they have been verified by the
global developer community.

3. Flexibility and control. You can change the code however you want.

4. Functional compatibility. Open standards ensure that software and systems work together seamlessly. XMPP, for
example, allows different chat clients to communicate with each other because they are built on the same open standard.
In proprietary systems, this is not always the case.

5. Innovation

6. No Vendor Lock-In

in general, use muffin thunderbird, use XMPP, use gajim

(https://gajim.org/) And dislike, otherwise I want to write more about how to use gajim (https://gajim.org/) with i2p


i2p + XMPP + encryption

This segment will cover using XMPP (an open standard for messaging) over I2P (Invisible Internet Project, a network
layer that allows applications to send messages anonymously) with encryption for additional security. We will look at
configuring several popular XMPP clients for this setup:

  • Pidgin: An easy to use and free chat client used by millions, it supports many chat protocols including XMPP. We will
    demonstrate how to use a PGP plugin for encryption.

  • Gajim: A full-featured XMPP client which is very flexible and extensible. We will be using a PGP plugin for encryption
    as well as OMEMO, a more modern cryptographic protocol.

  • Psi Plus: A powerful XMPP client designed for experienced users, we will also be adding PGP and OMEMO plugins for
    secure communication.

  • Dino: A modern and easy-to-use XMPP client, Dino offers end-to-end encryption to keep your conversations private.

i2p proxy configuration in client app

We will be covering how to configure I2P (Invisible Internet Project) proxies in your XMPP client applications. We’ll
cover two different I2P implementations: I2P Java (original I2P router written in Java) and I2Pd (a lightweight C++
implementation of I2P).

I2P – a network layer that allows applications to send messages across the internet in a way that is secure, encrypted,
and anonymous.

I2P gives you encryption and garanties that only a receiver and you see your traffic securely. But in the case of XMPP
we do not trust a public server. Server can replace your message and inject its own key and catch all.

End-to-End (E2E)

In the context of XMPP, we often don’t want to trust a public server with our messages. Even for the clear internet for
telegram or whatever it is true. Today you say “hi” but after a few years you will talk about deep personal stuff which
is obviously not for FBI guys but for only you and your friend.

Even though I2P can encrypt our traffic to and from XMPP server, the server itself can still read our messages. Every
server in the internet In a worst-case scenario, a malicious server could even replace your message, inject its own
encryption keys, and potentially capture all your future communications.

This is where End-to-End (E2E) encryption comes in. E2E encryption is a system where only the communicating users - you
and your receiver - can read the messages. It keeps your messages secure not just in transit, but also at rest when
they’re sitting on the server.

However, there’s a key challenge with E2E encryption: How do you securely exchange encryption keys at the start of a
conversation? And how can you trust these keys? This key distribution problem becomes crucial in a system where you’re
trying to minimize trust in external entities like public servers.

Many secure communication tools solve this problem using public key cryptography. Here, each user gets a pair of keys: a
public key (which is publicly shared) and a private key (kept secret). When you want to send a secure message, you use
the recipient’s public key to encrypt the message, and they use their private key to decrypt it.

But this introduces another problem: how can you be sure the public key belongs to the person you want to communicate
with, and not an attacker? A common solution is the use of digital certificates issued by trusted Certificate
Authorities (CAs), but this again introduces trust in a third party.

To deal with these issues, some secure communication tools use techniques like Trust On First Use (TOFU) or Web of Trust
models. Or blind trust for the first time. With TOFU, you accept the key or certificate the first time you see it, and
issue a warning if it changes later. With Web of Trust, keys or certificates are signed by other users, and you trust
them if they’re signed by users you trust.

Good way to use different messengers to confirm your public key. You write in the telegram begin of the token, in viber
end, by gmail - middle 🙂

Anyway you must trust yourself ;)

Confirm keys by another communication channel. I found twitter and github quite good for keeping your public keys.

So, while I2P gives us a secure transport, and E2E gives us secure content, we must still carefully navigate these
initial key exchange and trust challenges to maintain the security and integrity of our XMPP communications.

OMEMO keys exchange-trust problem

OMEMO is a cryptographic protocol that allows end-to-end encryption in XMPP for instant messaging. It’s constructed on
the Signal Protocol, which is also utilized by Signal Messenger, WhatsApp, and Facebook Messenger. PGP (Pretty Good
Privacy), an older standard for encryption, which is used for emails, isn’t built-in to as many XMPP clients as OMEMO
due to the latter’s ease of use, flexibility, and better security features. An important security feature that OMEMO
provides is forward secrecy, a trait PGP lacks. Forward secrecy ensures that an attacker can’t decrypt past or future
messages even if they compromise one of your encryption keys.

However, managing an OMEMO-based system’s security can be intricate. Elements like various keys for different accounts,
different XMPP clients, versions, plugins, and operating systems might all contribute to potential security risks. We
can only keep all these components updated and correctly configured to avoid these risks. Or use PGP and take it
seriously: sub-keys rotation, secure storing, backuping, strong passphrases and so on.

Group chats can also be end-to-end encrypted with OMEMO. Nevertheless, the security of a group chat is as strong as its
weakest link. If one participant’s device is compromised, an attacker might gain access to all chat messages.

Dealing with other devices’ keys is an essential part of maintaining secure communication.

When using OMEMO, every device has its own set of keys. When you log in from a new device, your device generates a new
set of keys. This set of keys is associated with your XMPP account and the device you’re using.

Here’s what you need to do with other devices’ keys:

  • Verification: You need to verify the keys of your contacts’ devices to ensure that the person you’re communicating
    with is who they claim to be. This is usually done via a method called fingerprint verification, where you compare the
    unique identifier (fingerprint) of their key with the one they provide you. If the fingerprints match, you can trust
    that the key is legitimate. In some cases, this can be done by scanning a QR code.

  • Device Management: Whenever a contact uses a new device to communicate with you, you’ll see a new key to verify. It’s
    important to keep track of the devices your contacts use. If a contact stops using a device, they should remove it
    from their list of devices. If a device that isn’t being used anymore is still in the list, it might be a sign that
    the device has been compromised.

  • Key Updates: Over time, due to a process known as “ratcheting,” the keys will change. This provides forward secrecy,
    meaning that if an attacker obtains a key, they can’t decrypt past messages. This means you’ll occasionally see new
    keys that need to be verified.

Remember, end-to-end encryption only works effectively when the keys used in the encryption process are handled
securely. Any lapse in key management could potentially open a window for attackers to compromise the conversation.

Good answers

https://crypto.stackexchange.com/questions/60082/is-omemo-vulnerable-in-case-of-compromised-jabber-server

If Alice has no prior information about Bob, she has no way to distinguish these cases, no matter how secure the protocol is. It’s the same for OTR, OMEMO, WhatsApp, Signal, the post, or Twitter.

https://crypto.stackexchange.com/questions/31418/signal-vs-telegram-in-terms-of-protocols

XMPP send encrypted message to device NOT to op

We will explain how XMPP can send encrypted messages to a specific device rather than to the user, which enhances
security when a user is signed in on multiple devices.

Psi Plus UI accept keys for new devices, files and maybe something else not in messages and it is a problem if you lose OMEMO keys

We will be discussing some quirks of the Psi Plus user interface, especially in relation to managing encryption keys.
We’ll look into the potential problems when OMEMO keys are lost and how to prevent these issues.

Psi 2 hot 2 encrypt - double encryption compatible only with psi

This part will cover “double encryption” in Psi, a feature where messages are encrypted twice for added security.
However, it is important to note that this feature is only compatible with the Psi client.